Data Transfer Object

重い呼び出しを複数呼ぶのを避けるためのパターン

なのでremoteなものが前提っぽいが、↓にもローカルの話

localのパターンも有る

スレッド間のやりとり

ただ、ローカルDTOは上記の通りbad patternとして紹介されてる

悪い場合

中には、DTO は Service Layerの API の一部だという人もいます。

他にも、後から分散するかもしれないから DTO を使っておく

良い場合

DTOのようなものを使うとよいのは、 プレゼンテーション層のモデルとドメインモデルとの間に 大きなミスマッチがある場合です。

miyamonz.icon

どちらにせよ、DTOは転送可能、シリアライズ可能であるがゆえに表現力が落ちる

よりコードや型に意味をもたせるほうが扱いやすい

DTOだけでモデリングして、型や制約などが付与できなければ、脳内で変換コストが伴う

転じて、単にシリアライズしたオブジェクトを指すことが多い(要出典

異なる文脈の間でやり取りするためのデータ型

json的な

元来の使われ方は、やってることは似てる or 同じだが、意義はちょっと違うところにあるのだけ注意

DTOについて考えるときは

シリアライズされたJSONと、デシリアライズ(perse)された何らかの型　がどのように異なる特徴を持っているのか

シリアライズはなんのために行っているのか

DBに投げるためか

別のユーザに送信するためか

…

デシリアライズ、型の方は、JSONと違ってどのように情報が増えたり、制約が増えたり、利便性があがっているのか

あたりを考えるといいだろう

特定の型の値をprisma経由でread writeするだけでも、DTOとしてのjsonに一回挟むだけで、かなり便利になる